Post not yet marked as solved
There is a known issue where an iPhoneSimulator SDK is misdetected as MacOSX SDK — unfortunately the fix for this didn't make it into beta 2. When you capture a types log and LogConfiguration shows a macOS SDK being chosen for a simulator binary that's that issue. If you are seeing this symptom and don't see a macOS SDK selected in the types log, please let us know through FeedbackAssistant (ideally with the types log attached)!
Post not yet marked as solved
The fundamental problem appears to be the mismatch between the target triple
SwiftASTContextForExpressions::LogConfiguration(SwiftASTContext*)0x7ff801a514c0: Architecture : x86_64-apple-ios13.5.0-simulator
and the chosen SDK:
SDK path : /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.16.sdk
For that triple we should have picked an iPhoneSimulator SDK. It would be interesting to see the rest of the log to understand why this happened. Would you be able to attach the full log to a Feedback Assistant ticket?
Post not yet marked as solved
Could you capture a types log by putting "log enable lldb types -f /tmp/types.log" into ~/.lldbinit-Xcode an relaunching Xcode and reproducing the error?
If it doesn't show up in the LLDB console the types usually contains the underlying error. You can either post it here, or look through it yourself and read the blocks around "LogConfiguration" closely. They show how the Swift and Clang compilers that are embedded into LLDB were initialized for your app. Usually they contain a hint why things go wrong.
Post not yet marked as solved
Thank you very much for the reproducer! Upon analysis we could identify two separate issues, that both have the very similar symptoms.First is the handling of label debug info in LLVM bitcode, which is the same issue that is being tracked by FB7640880, and needs to be resolved in Xcode itself. These are the errors referring to DILabel. The second however, can only be resolved by recompiling the Unity libraries with a newer version of clang. It looks like the library was produced by Xcode 9.2, which had an issue updating loop debug metadata during inlining. This issue has been resolved in newer versions opf clang. These are the errors referring to !llvm.loop.Note that neither of these issues can affect the generated code, it only affects the quality of the debug information for the affected object files.
Post not yet marked as solved
Is /Users/[censored]/Pods/Google-Mobile-Ads-SDK/Frameworks/GoogleMobileAdsFramework-Current/GoogleMobileAds.framework/GoogleMobileAds.a a file that you compiled locally (perhaps indirectly via CocoaPods) or is this a static (.a) archive that was built with an earlier version of Xcode (perhaps because you/CocoaPods downloaded from some place else)?
Post not yet marked as solved
One additional question specifically for steipete: Does your file that you are getting the warning reported for also contain named labels?
Post not yet marked as solved
Would you be able to share a project that reproduces the issue? You can just attach it to the FB. If you cannot share source code, I might be able to read something out of the bitcode object files, too.thanks!
Post not yet marked as solved
Is any one of you able to share a project that reproduced the issue?
